home *** CD-ROM | disk | FTP | other *** search
- Editor's Note: Minutes received 8/12
-
- CURRENT_MEETING_REPORT_
-
- Reported by Steve Hardcastle-Kille/UCL, Doug Simmons/IBM and Justin
- Walker/Apple
-
- Minutes of the OSI Directory Services Working Group (OSIDS)
-
- Comments on Agenda
-
- Mark Knopper sent apologies for non-attendance and then turned up.
-
- Here follow comments on the Minutes from San Diego (OSI-DS-MINUTES 7),
- particularly relating to action items from that meeting:
-
-
- o Regarding maintenance of RFC-1274, it is Steve and Paul Barker who
- will be involved, not Colin as the Minutes claimed.
-
- o Eric Huizer's strategy document is ready (comments will be made
- later in the Minutes).
-
- o Chris's documents (OSI-DS 14, 16, 17, 19) have not been revised.
- This will be done by the next meeting. Mark Knopper has taken up
- the network schema.
-
- o Documents OSI-DS-12, 23, 24 have been revised and submitted to the
- IESG. As suggested in the previous meeting, Steve Hardcastle-Kille
- read NADF 175 (which has been revised to NADF-(***Didn't get the
- reference***). He cleared up some misconceptions regarding he NADF
- position, but overall, his position did not change from the last
- meeting.
-
- o Wengyik continued to work on interoperability issues. However, he
- had no input, since he was not present.
-
- o There will be a NADF meeting next week (that is, the week of 7/20).
-
- o The QOS experiments will be discussed as indicated in the Agenda.
-
- o The JPEG schema was reviewed. However, the Schema group had not
- yet formed, so this item was continued. Paul Barker was to
- establish the schema group, but this had not done this because of
- overload due to Steve's departure to the ISODE Consortium.
- Resources were requested (volunteers were solicited; no response
- was heard from Russ and Mark).
-
- o The Character Set experiment wasn't discussed because Geir Pederson
- wasn't present. The action was continued.
-
- o Tim Howes brought us up to date on the DIT Counting effort. The
- code has been written, and will appear in the next ISODE Consortium
-
- 1
-
-
-
-
-
- release of QUIPU. The item was continued.
-
- o Work on schema publishing was completed and will be discussed
- later.
-
- o The action item on preferred names was continued (no one was
- present to speak on the subject).
-
- o Steve H-K finished the revision of RFC-1279 , with Wengyik
- consulting. The paper has not actually been updated (in its
- electronic form). It will be circulated.
-
- o The lightweight protocol note (LDAP) was revised and circulated.
-
- o Steve Hardcastle-Kille looked into possible ISO alternatives to SOS
- (the Simple OSI Stack). There are no current ISO proposals
- addressing the SOS issues, but John Day (from BBN) has circulated a
- document (in OSI circles) on the OSI upper layers. Reviews are not
- complete, but this document does not seem to be an answer.
-
-
- There were no Matters Arising. We therefore moved right into the
- liaison reports.
-
-
- 1. RARE (Eric Huizer)
- As reported at the last meeting, WG3 is no more. The new RARE
- structure has eight Working Groups, of which one, WGNAP (the
- Working Group for Network Application support), will undertake
- directory services (as well as time protocols, etc.). A major
- problem is that, while a Chair has been identified and wants to
- undertake the work, he can't get permission to do the job. WGNAP
- hopes to meet in November. A distribution list has been set up for
- other than directory service issues. WGNAP will continue to use
- OSI-DS for its directory service discussions. The Working Group
- has small budget from RARE, provided they can come up with a
- priority list of tasks. This could be applied to travel.
-
- 2. OSI/CCITT (Ken Rossen)
- There were two significant events to report. ISO 9594 passed to
- DIS. The most significant change was in the area of access control
- (replication and an extended information model). DISP (shadow);
- DOP (binding) are new protocols. An access control context is a
- combination of levels of access control. The US pushed
- successfully for simplified access control: this only allows a
- decision to be made at administration points (new in model); a
- decision isn't overridden by lower levels of the tree. As of the
- last editing meeting, merged text was produced. Unfortunately, the
- circulated stuff was a mess. There is a good copy, dated 12/25/91
- (hence it is called ``the Christmas text'').
- The second event occurred in May. When ISO SC21 met in Ottawa, the
-
- 2
-
-
-
-
-
- Directory Services Group also met, and changes to the Standard were
- discussed (with a 2 year target, down from the usual 4). Use of
- OSI management (CMIP) to manage the directory was put on hold,
- since the responsible party (from the US) resigned. Work on
- authentication could be undertaken as there is support for small
- changes, e.g., certificate revocation. This will wait for the next
- meeting to commit effort to this work. There was a feeling that
- there is need for closer work with (ISO) security folks for a more
- sophisticated security model. Given upper layer security services,
- there is a need for a scheme to apply to directory services. Also,
- there is a new edition of ASN-1 encoding rules, which could effect
- directory. Distinguished encoding rules were introduced that are
- different from those currently used by the directory. There is
- need to work out conflicts. This could affect digital signatures.
- The 1992 X.500/9594 should progress at the next editing meeting in
- Orlando, in the fall of `92 (this will involve serious cleanup.
- Rows of ducks will be set up at a US meeting in Nashua this week.).
-
- 3. OIW (Russ Wright)
- The OIW continued work on standardized profiles for DAP, replacing
- agreements from the OIW and EWOS. They are on schedule for results
- by the end of year. A joint meeting was held with the X400 SIG to
- look at MHS and the directory. Their desires right now are
- unclear, but they will provide a clearer specification.
- The IGOSS document was reviewed. This is a combined document
- representing input from GOSIP, the power industry, and the
- manufacturing industry. This requires `92 directory extensions,
- including replication. They were asked to review POSIX documents
- relating to directory services. The documents themselves are in
- the mail.
-
- 4. DISI (Chris Weider)
- Documents describing advanced directory usage and how to get
- registered in the directory have been worked on, but not
- circulated. A revision RFC-1292 has been worked on Four new papers
- have been prepared: a pilot catalog, a description of DIT setup,
- the directory naming philosophy, and a schema for restaurant
- information.
-
- 5. AARN Mark Prior
- There is not much happening at this time. AARN is not willing to
- commit to further work, nor are they willing to say no to further
- work. They are waiting for December (***Why?***). There are
- currently 40000 entries in their directory, and they have just
- added affiliates. Master and slave machines will be soon be
- upgraded.
-
- 6. NADF (Marshall Rose/Einar Stefferud)
- The last NADF meeting was in April, the next will be next week
- (7/20). Discussion of vendor plans at the last meeting was
-
- 3
-
-
-
-
-
- exciting (depressing?). Several documents are available. One
- provides a naming scheme for a country (discussing principles), and
- a second provides an application of these principles to the US. A
- third discusses the theory and practicality of directory security.
- This latter is up for more debate. There is a desire for simple
- authentication, but this may be difficult to protect from replay
- attack. The recommendation may be for protected passwords. The
- documents should become RFCs (but some can't even seem to be put
- into the politically *in*correct PostScript format). Marshall will
- provide copies for Steve Hardcastle-Kille. None of the twelve
- vendors present supported any but simple authentication. None
- would commit to supporting `92 extensions (except one who was
- planning to support the extended information model). In short,
- things don't seem to be going very well (according to public
- comment at the meeting. This is born out by Ken's observations at
- COS). There seems to be more positive support for simplified access
- control (over the basic version).
- Ken noted that they think they've fixed NADF complaints. Time was
- spent at the Ottawa meeting on defect resolution (there is a
- directory implementor's guide; see Ken). There seems to be some
- interplay between ISO, NADF.
-
-
- As no pilot project representatives were present, we continued on with
- the rest of the Agenda.
-
- The Naming Guidelines Document, the UFN Document, and the Document
- Defining String Representation of UFN's. All three were submitted in
- April to the IESG. They are expected to move forward by end of this
- month.
-
- The Strategy Document. The Strategy document (based on Steve's
- original) was much modified, based on comments received. Most of the
- original was retained, but with editing and restructuring. One of the
- main criticisms was references to other RFCs without indicating the RFC
- content. Eric's solution was to pull the main points from the RFCs in
- question, using reference only for detail. He added deployment details
- and requirements. Therefore, there were a lot of references to DISI
- papers. The ASCII version (as posted) was quite unreadable. Apologies
- were tendered, along with a promise to fix it. Comments were requested.
-
- One comment at the meeting: a possible extension involving the use of
- large data values was questioned. The response was that this is only a
- *possible* extension, not a planned (or required) one. An observation
- was made that all items in this section (of the document) could be
- termed controversial. The main point is that the model is not rigid:
- if deployment experience indicates that a change is needed, it will be
- addressed.
-
- Regarding progress to ID-hood for the strategy document, the approval of
- the other authors is needed. Then an informational RFC can be
-
- 4
-
-
-
-
-
- submitted. Steve Hardcastle-Kille wants to see this done reflecting an
- IAB/IESG consensus (as was done, e.g., for RFC-920). He wants the
- submission and publication to reflect IAB policy. It is unclear what
- the tradition is. It was felt that we should have OSI-DS consensus, so
- a sense of meeting was taken; there were no votes against the document,
- but there were a large number of abstentions (from those who had not
- read it yet). Eric will take changes, publish the new document as an
- RFC (both text and PS formats), and get it into the IESG stream. The
- attendees seemed to favor not waiting for the next meeting, given the
- consensus here (all who had read approved).
-
- Eric noted that none of the three documents mentioned earlier showed up
- on the IESG action list that he gets. This was deemed to be a dropped
- ball. Eric will follow up to determine how the ball got dropped and
- assure that it doesn't happen again.
-
- Tim Howes: Some comments on the schema document, from Colin Robins
- (sent by email to the OSI-DS list), were distributed. Given that the
- schema is rapidly changing, the idea of storing (a description of) the
- schema in the DIT has been investigated. Tim looked first at the '92
- Standard, which was very complicated. The `92 information is in his
- document, but comments he's received indicate that it (the `92 content)
- should be pared down. The document talks about representing attribute.
- information in the directory, although no syntaxes were defined.
- Although the document says this work will be a subset of `92, Tim
- doesn't think it really is. We must decide on compatibility with `92
- vs. having something ``now''.
-
- The question was asked: what are the areas of incompatibility? Among
- others, there is the attribute syntax, which is difficult to figure out.
- From Colin: how does one go from an OID to an identification of
- information it represents?
-
- It was noted that an OID tree may be useful by itself, independent of
- other uses. There is a bootstrap problem with this. The issue is where
- to find a description of information, and what is the efficiency hit?
- Using well-known locations in the DIT may avoid a recursive upward walk
- of the tree. This also assumes a configuration run that tells the DSA
- what well-known locations to check. The directory doesn't do dynamic
- interpretations of OIDs. It was observed that ``compatibility w. 92''
- and ``something that works'' may not be exclusive. Two actions
- resulted. The first was to define the OID tree. The second was to
- revise the schema notes in light of the discussion. Tim took both.
-
- QOS Experiments. There was no change from the previous meeting. This
- work has not been a priority (although there is work ``scheduled'', to
- be done on Macintosh DUA). Sylvain noted that code that he has seen
- doesn't match the RFC (which may have changed since he last checked it).
- Tim wanted this taken off the Agenda, since it isn't a priority. He
- would like to surprise us with progress when it happens.
-
- JPEG. The JPEG attribute is not in the schema, but there is code to
-
-
- 5
-
-
-
-
-
- handle it in ISODE. Russ would like this to be its end. Proposed to
- carry over to next time when the schema group is represented (and so it
- shall be).
-
- Character Set. (Geir Pederson was not present): Again, the schema
- group was an issue. A discussion commenced on how to get this done.
- IANA was suggested as a source of help. A problem with this is that we
- would need to find someone with directory experience to take on some
- editing load. It was recommended that we talk with IANA, then worry
- about the short-term.
-
- Selection of the time and place for the next meeting involved two
- choices: INTEROP (October in San Francisco), and the next IETF
- (November in Washington). A vote marginally favored the November IETF
- meeting, and this was agreed on.
-
- DSA and DUA Metrics (OSI-DS33 ,OSI-DS 34)
-
-
- o Measure pilot projects' success.
-
- o Deliverables - metrics papers for:
-
- - DUAs.
- - DSAs.
- - Pilots' metrics.
-
-
- o No absolute measure of goodness or badness of DUAs; there's SOME
- importance to the numbers, though.
- Comments on these papers:
-
- o Set up an FTP ID to keep the OSI-DS documents in for easy retrieval
- before these meetings. SEH to address.
-
- o DSA Document - need hands-on experience to tell if this document is
- really worthwhile and accurate. (comment by Eric Huizer).
-
- o DUA document - section l2 (query resolution) not very clear what
- one should enter to initiate the query (comment by Time Howes).
-
- o DUA document - 5 steps to enter a query as opposed to on line via
- UFN.
-
- o BOTH - is this a Consumer Reports on DUAs/DSAs? SEH - the user
- endorsement section contains the necessary feedback for analysis.
-
- o BOTH - there were comments from Paul Andre, were they being
- incorporate?
-
-
- 6
-
-
-
-
-
- o DSA Document - section 5,need to discuss the environment - how can
- we measure implementations on different machines? (comment by Tim
- Howes).
-
- o DSA Document - need more than lOO to 5OOO entries for accurate
- testing (comment by Tim Howes).
-
- o DSA Document - need more discussion on security aspects (unknown).
-
- o BOTH - metrics will not be useful until they are tried out/tested
- against (unknown).
-
- o BOTH - make measurements available via informational RFC.
-
- o DSA Document - other implementations tested besides QUIPU? (comment
- by Sylvain Langlois) (Pissaro(sp?), ICL, Dirwiz....)
-
- o S. Hardcastle-kille: How many of us are responsible for DUA
- implementations? Would it be worthwhile to make these documents
- publicly available? SEH to use RFC for informational test until
- next meeting for feedbacks.
-
- E. Huizer To do Siemens DSA.
- T. Howes/R. Wright Will do DUAs we'll evaluate findings at
- next meeting.
- S. Hardcastle-Kille To get these published as RFCs.
- Everyone To see that these get filled in when DUA's
- and DSA's tested.
-
-
- o Comment - what's the difference between RFC 1292 and DS 33 and 34?
- SEH: 33 and 34 much lower level (and more work to fill out) S.
- Hardcastle-Kille suggested that the vendor be asked if they filled
- out a 33 or 34 before answering to RFC l292.
-
-
- Representing Network Infrastructure Information in X.5OO (Mark Knopper)
- Draft circulated.
-
- Soft Pages Project (Steve Hardcastle-Kille).
-
-
- o Comment - IP name space: defining an address hierarchy. You
- really don't need that, what advantage over a flat design?
-
- o Comment - Network elements diagram is a network topology. What
- happens if that changes? (comment by Tim Howes).
-
- o Comment - (Mark Hopper).
-
- 7
-
-
-
-
-
- - Not sure if this resolves the problem.
- - It is too inefficient.
- - How do you get the bootstrap up and running?
-
-
- o ACTION * - Mark Knopper to document how we might use this (where
- might the holes be).
-
- o Comment - this tree can be kept small just by keeping the DSAs
- ``near'' you in the DIT, as they are the only ones which should
- interest you for cost purposes.
-
- o Comment - need FTP address for this document (FTP.TOHOKU.AC.JP).
-
- o Comment - do we need a Working Group to address this problem?
-
- o ACTION* Thomas Johansen and Mark Knopper to reconsider their
- approaches and attempt some kind of convergence.
-
-
- LDAP (OSI-DS 26, OSI-DS 27)
-
-
- o Comment - kerberos and simple authentication: do we think this is
- worthwhile and should it be added to the document before it becomes
- an RFC? (Tim Howes).
-
- o S. Hardcastle-Kille: Because it is implemented and deployed, then
- it should be documented.
-
- o Comment - we should submit this to the Standards committee as soon
- as possible.
-
- o Comment - suggestion that we have Christian look at it, as he has
- strong views on the subject.
-
-
- DSA Naming (OSI-DS l3)
-
-
- o Issue: Avoiding Deadlock.
-
- o Comment - the DSA must be named higher in the tree (country level)
- to prevent deadlock, but you do not insure uniqueness.
-
- o Comment - Erik seemed to remember opposition by the Pissaro group,
- but could not elaborate.
-
- o Comment - using subtrees seems to be the way we fix things we can't
- fix via X.5OO.
-
- 8
-
-
-
-
-
- o ACTION* S. Hardcastle-Kille: To re-write the paper to using
- non-QUIPU language and references.
-
- o Comment - Erik not comfortable, seems like a way to fix a design
- problem in QUIPU. Need input from other DSA vendors.
-
- o ACTION* S. Hardcastle-Kille: To drop this as an OSIDS item and
- take it up as a design issue with ISODE.
-
-
- Action Items
-
-
-
- Chris Weider Update OSI-DS 14, 16, 17, 19 (carried forward)
-
- E. Huizer Progress Naming Guidelines, DN Syntax, UFN, and
- LDAP and LDAP Syntaxes as RFCs.
-
- Do Siemens DSA.
-
- T. Howes/R. Wright Will do DUAs we'll evaluate findings at next
- meeting.
-
- S. Hardcastle-Kille Get these published as RFCs.
-
- Everyone to see that these get filled in when DUA's and
- DSA's tested.
-
- M. Knopper To document how we might use this (where might
- the holes be).
-
- T. Johansen/M. Knopper Reconsider their approaches and attempt
- some kind of convergence.
-
- S. Hardcastle-Kille to re-write the paper to using non-QUIPU
- language and references.
-
- Drop this as an OSI-DS item and take it up as a
- design issue with ISODE.
-
- Revise Charter.
-
- S. Hardcastle-Kille/E. Huizer Discuss IANA support for Schema
- Management.
-
- T. Howes Write note on representation of OID Trees in
- Directory.
-
- P. Barker Publish Metric Papers as Internet Drafts.
-
- S. Sataluri Collect DUA survey results and publish as
- Internet Draft.
-
- 9
-
-
-
-
-
- Attendees
-
- Ed Albrigo ealbrigo@cos.com
- Claudio Allocchio c.allocchio@elettra.trieste.it
- C. Allan Cargille cargille@cs.wisc.edu
- Jodi-Ann Chu jodi@uhunix.uhcc.hawaii.edu
- James Conklin jbc@bitnic.educom.edu
- Robert Cooney cooney@wnyose.nctsw.navy.mil
- Curtis Cox ccox@wnyose.nctsw.navy.mil
- Urs Eppenberger eppenberger@switch.ch
- Ray Freiwirth 5242391@mcimail.com
- Jisoo Geiter geiter@gateway.mitre.org
- Arlene Getchell getchell@nersc.gov
- Joan Goldstein j_goldstein@tnpubs.enet.dec.com
- Steve Hardcastle-Kille s.kille@isode.com
- John Hawthorne johnh@tigger.rl.af.mil
- Tim Howes Tim.Howes@umich.edu.
- Erik Huizer huizer@surfnet.nl
- Takashi Ikemoto tikemoto@xerox.com
- Kevin Jordan kej@udev.cdc.com
- Jim Knowles jknowles@trident.arc.nasa.gov
- Sylvain Langlois Sylvain.Langlois@der.edf.fr
- Thomas Lenggenhager lenggenhager@switch.ch
- John McKenna mckenna@ralvm12.vnet.ibm.com
- John Murray murray@premenos.sf.ca.us
- Mark Needleman mhn@stubbs.ucop.edu
- William Nichols nichols@wick.enet.dec.com
- Eric Nowak nowak@ans.net
- Rakesh Patel rapatel@hardees.rutgers.edu
- Mark Prior mrp@itd.adelaide.edu.au
- Sheri Repucci smr@merit.edu
- Jim Romaguera romaguera@cosine-mhs.switch.ch
- Marshall Rose mrose@dbc.mtview.ca.us
- Rich Rosenbaum rosenbaum@lkg.dec.com
- Kenneth Rossen kenr@isc.com
- Srinivas Sataluri sri@qsun.att.com
- Douglas Simmons Mark Smithmcs@umich.edu
- Einar Stefferud stef@nma.com
- Panos-Gavriil Tsigaridas tsigaridas@fokus.berlin.gmd.dbp.de
- Justin Walker justin@apple.com
- William Warner warner@ohio.gov
- Chris Weider clw@merit.edu
- Brien Wheeler blw@mitre.org
- Scott Williamson scottw@nic.ddn.mil
- Steven Winnett swinnett@bbn.com
- Russ Wright wright@lbl.gov
- Yung-Chao Yu yy@qsun.att.com
-
-
-
- 10
-